In network functions virtualization (NFV), a general-purpose hardware device and a virtualization technology are used to fulfill a function of a dedicated device in a conventional network, so as to reduce high deployment costs of the dedicated device. Software is not bound to dedicated hardware, so that a function of a network device no longer depends on the dedicated hardware. In addition, cloud computing is used, so that resources can be shared fully and flexibly, new services can be rapidly developed and deployed, and automatic deployment, auto scaling, fault isolation, fault self-recovery, and the like can be implemented based on an actual service requirement. In an NFV architecture, a party that receives an instantiation request and performs instantiation processing on a corresponding service (deploys the service) according to the request is referred to as a virtualization service provider (service provider for short), and a party that initiates the instantiation request is referred to as a service requester.
A virtualized network service (NS) in NFV may be, for example, an IP multimedia subsystem (IMS) network service, or an evolved packet core (EPC) service. One NS may include multiple virtualized network function (VNF) modules, which are also referred to as virtualized network elements. A VNF is a software implementation of a network function that may be deployed in an NFV infrastructure. During virtualization deployment of an NS, a service requester first needs to submit network service descriptor (NSD) to a service provider. The NSD mainly describes a topology of the network service and descriptor of included VNFs (VNF descriptor, VNFD). In the topology, a connection between VNFs is described by using virtual link (VLD). The VNFD describes a constitution, for example, software that runs, and information about a required virtual resource, of each VNF. The virtual resource includes a CPU resource, a storage resource, and the like.
FIG. 1 is a schematic diagram of connecting multiple VNFs by using a virtual link (VL) in NFV. A network service (NS) shown in FIG. 1 mainly includes three VNFs that are connected by using VLs. Each VNF is connected to a VL by using a connection point (connection point, CP). A connection point may be an address of a virtual network adapter or a virtual port number. Descriptor of a virtual link mainly includes a connection point and a connection type, and may further include a parameter such as a root node requirement, a leaf node requirement, service quality, or an interface. A virtual link VL1 in FIG. 1 includes connection points: a CP2, a CP3 and a CP4, and a connection type of the CPs may be an E-TREE tree mode or an E-LAN bus mode. A VL2 includes connection points: a CP1 and a CP5, and a connection type of the CPs is an E-LINE point-to-point mode. As defined in NFV, one connection point can be connected only to one VL, and one VL includes only one connection point for one VNF instance. If one VNF instance needs to be connected to multiple VLs, the VNF instance needs to include multiple connection points, for example, because a VNF1 and a VNF3 in FIG. 1 each are connected to two VLs, the VNF1 and the VNF3 each include two connection points.
Currently, three connection types are defined in NFV, and are respectively the E-LINE (point-to-point mode), the E-TREE (tree mode), and the E-LAN (bus mode). FIG. 2 shows three connection types of virtual links. A virtual link of the E-LINE type can be used to connect only two VNFs, that is, the VL of this type includes only two connection points. A virtual link of the E-TREE type can be used to connect multiple VNFs, and a root node and a leaf node are defined in this type. For example, in FIG. 2, an end connected to a VNF1 is defined as a root node, and ends connected to a VNF2 and a VNF3 are defined as leaf nodes. Therefore, the root node (VNF1) can send a message to any leaf node (that is, send messages to the VNF2 and the VNF3). However, the leaf nodes can send a message only to the root node, but the leaf nodes cannot send a message to each other, that is, the VNF2 cannot send a message to the VNF3. The E-LAN bus type may also be used to connect multiple VNFs. Each VNF can send a message to a bus. The bus may send a message to all other VNFs on the VL in a broadcast manner. Each VNF checks the message after receiving the message. The message carries address information of a target VNF. Only the target VNF processes the message after receiving the message, and other VNFs discard the message after receiving the message.
An NSD may include one or more service deployment flavors. Each deployment flavor includes a deployment configuration parameter set of a network service. Requirements on various resources, such as a CPU and a memory, of the service are specified by deployment configuration parameters in the deployment configuration parameter set. Different service deployment flavors separately correspond to different service indicators, for example, a low indicator, a medium indicator, and a high indicator. The service may be initially deployed according to a low-indicator flavor. When the service runs for a period of time and reaches a peak hour, a service requester may require auto scaling to be performed on the network service, for example, require the network service to be scaled to a high-indicator deployment flavor. After a VNF resource scaling or new instance adding procedure is completed, a network functions virtualization orchestrator (NFVO) performs resource updating on a VNF. After the resource updating is completed, the NFVO returns an auto scaling success response to the service requester.
For VNF descriptor used in the prior art, scaling and a connection of only one VNF are considered during auto scaling. However, one NS may include multiple VNFs, and a deployment flavor requires an instance to be added only for one or more of the VNFs. The prior art does not show how to connect the one or more VNFs to another VNF in the NS after a quantity of instances of the one or more VNFs is changed.
As shown in FIG. 3, in the E-LINE mode, one NS includes two VNFs: a VNF1 and a VNF2. Because a deployment flavor A requires only one instance of the VNF1, a type of a VL between the VNF1 and the VNF2 is the E-LINE. As the service runs, when the service needs to be automatically scaled to a flavor B, two instances of the VNF1 are required. Because the type of the VL between the VNF1 and the VNF2 is initially the E-LINE mode in a definition of an NSD, and one instance of the VNF1 is added when the service needs to be scaled to the flavor B, the original VL of the E-LINE mode apparently cannot meet the requirement, and cannot connect an instance 2 of the VNF1 to an instance 1 of the VNF2.
For the E-TREE and the E-LAN, if a VNF instance and a corresponding connection point are newly added, because the newly added VNF instance and connection point are not included in a definition of an initial VL, when a service is automatically scaled to a flavor B, the newly added connection point cannot be directly connected to the original VL.
In conclusion, in a current auto scaling solution in which VNF descriptor and a VL are used, only how to add a VNF instance is considered, but how to connect the newly added VNF instance to another VNF to which the newly added VNF instance needs to be related is not considered in the current solution. Therefore, according to a current description of an NSD, the newly added VNF instance cannot be successfully connected to another VNF instance in a service.